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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The objective of this document is to address the Inter-IMS Network to Network Interface (II-NNI) consisting of Ici and 
Izi reference points between IMS networks in order to support end-to-end service interoperability. 

The present document will address the issues related to control plane signalling (3GPP usage of SIP and SDP protocols, 
required SIP header fields) as well as other interconnecting aspects like security, numbering/naming/addressing and 
user plane issues as transport protocol, media and codecs actually covered in a widespread set of 3GPP specifications. A 
profiling of the Inter-IMS Network to Network Interface (II-NNI) is also provided. 

Charging aspects will be addressed as far as SIP signalUng is concerned. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

example: text used to clarify abstract rules by applying them literally. 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions, as specified in 3GPP TS 22.228 [9]. 

IP multimedia session: as specified in 3GPP TS 22.228 [9] an IP multimedia session is a set of multimedia senders and 
receivers and the data streams flowing from senders to receivers. IP multimedia sessions are supported by the IP 
multimedia CN Subsystem and are enabled by IP connectivity bearers (e.g. GPRS as a bearer). A user can invoke 
concurrent IP multimedia sessions. 

non-roaming II-NNI: the II-NNI between IMS home networks. 

roaming II-NNI: the II-NNI between a visited IMS network and the IMS home network. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [120] apply: 

MSC Server enhanced for ICS 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Ici Reference Point between an IBCF and another IBCF or I-CSCF belonging to a different IM CN 

subsystem network 
Izi Reference Point between a TrGW and another TrGW or media handling node belonging to a 

different IM CN subsystem network 
Mi Reference Point between a BGCF and CSCF 

Mm Reference Point between a CSCF/BGCF/IMS ALG and an IP multimedia network. 

Mw Reference Point between a CSCF and another CSCF 

Mx Reference Point between a CSCF/BGCF/MSC Server enhanced for ICS and IBCF 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 

ACR Anonymous Communication Rejection 

B2BUA Back 2 Back User Agent 

BGCF Breakout Gateway Control Function 

CAT Customized Alerting Tone 

CB Communication Barring 

CCBS Completion of Communications to Busy Subscriber 

CCNR Communication Completion on No Reply 

CDIV Communication Diversion 

CDIVN Communication Diversion Notification 

CRS Customized Ringing Signal 

ECT Explicit Communication Transfer 

FA Flexible Alerting 

HOLD Communication HOLD 

CW Communication Waiting 
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IBCF Interconnection Border Control Function 

ICB Incoming Communication Barring 

ICS IMS Centralized Services 

I-CSCF Interrogating CSCF 

II-NNI Inter-IMS Network to Network Interface 

IM Instant Messaging 

IMS-ALG IMS Application Level Gateway 

MCID Malicious Communication IDentification 

MRFC Media Resource Function Controller 

MSRP Message Session Relay Protocol 

MWI Message Waiting Indication 

NA(P)T-PT Network Address (Port-Multiplexing) Translation-Protocol Translation 

NNI Network to Network Interface 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy CSCF 

PNM Personal Network Management 

PRES Presence 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

TrGW Transition Gateway 



Overview 



Interconnection between two different IM CN subsystems shall be guaranteed in order to support end-to-end service 
interoperability. For this purpose, Inter-IMS Network to Network Interface (II-NNI) between two IM CN subsystem 
networks is adopted, according to the assumptions coming from 3GPP TS 23.002 [3] and 3GPP TS 23.228 [4]. 

Aiming to support the delivery of IMS services between two separated IM CN subsystems, protocol interconnection has 
to occur: 

at a control plane level, in order that IMS procedures can be supported. In this case the adopted reference point is 
the Ici; and 

at a user plane level, where media streams are exchanged over the Izi reference point. 

The management of IP multimedia sessions is acted by using SIP. The transport mechanism for both SIP session 
signalling and media transport is IPv4 (IETF RFC 791 [2]) or IPv6 (IETF RFC 2460 [7]). The 3GPP profile of SIP 
defining the usage of SIP within the IM CN subsystem is specified in 3GPP TS 24.229 [5]. Example call flows are 
provided in 3GPP TR 24.930 [6]. 

The general interconnection model is shown in Figure 4.1. 




II-NNI 




Figure 4.1 : Interconnection IVIodel for IM CN subsystems 

The possible functional entities involved in the signalling plane interconnection (IBCF, I-CSCF, P-CSCF, BGCF and 
MSC Server enhanced for ICS) and in the user plane interconnection (TrGW) are specified in 3GPP TS 24.229 [5], in 
3GPP TS 24.292 [121] and in 3GPP TS 29.162 [8]. 

IP Version interworking is described within 3GPP TS 29.162 [8]. 
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Reference model for interconnection between IIVI CN 
subsystems 



5.1 



General 



Figure 5.1 illustrates the architecture diagram given in 3GPP TS 23.228 [4] showing the Inter-IMS Network to Network 
Interface (11-NNI) between two IM CN subsystem networks. 



P-CSCF 



MSC Server 

enhanced 

for ICS 




S-CSCFl 

7 



^ ^Mx 



^ 


P-CSCF 


^ 


Mx 






> 


MSC Server 

enhanced 

for ICS 





Signalling 

^^ IM CN subsystem network A IM CN subsystem network B 

Figure 5.1.1 : Inter-IMS Network to Network Interface between two IM CN subsystem networks 

The protocols over the two reference points Ici and Izi make up the Inter-IMS Network to Network Interface. 

The Ici reference point allows IBCFs to communicate with each other in order to provide the communication and 
forwarding of SIP signalling messaging between IM CN subsystem networks. The Izi reference point allows TrGWs to 
forward media streams between IM CN subsystem networks. 

IMS roaming performed by using II-NNI is considered, when the IBCFs are inserted at the network borders. 

Whenever the Inter-IMS Network to Network Interface is used to interconnect two IM CN subsystem networks 
belonging to different security domains, security procedures apply as described in 3GPP TS 33.210 [10]. 



5.2 Functionalities performed by entities at the edge of the 
network 

5.2.1 Interconnection Border Control Function (IBCF) 

An IBCF provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection 
between IM CN subsystem networks by using Ici reference point. According to 3GPP TS 23.228 [4], IBCF can act both 
as an entry point and as an exit point for a network. 

The functionalities of IBCF are indicated in the 3GPP TS 23.228 [4] and specified in 3GPP TS 24.229 [5]. They 
include: 

- network topology hiding; 

application level gateway (for instance enabling communication between IPv6 and IPv4 SIP applications, or 
between a SIP application in a private IP address space and a SIP application outside this address space); 

controlhng transport plane functions; 

controlling media plane adaptations; 
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screening of SIP signalling information; 

selecting the appropriate signalling interconnect; and 

generation of charging data records. 
Based on local configuration, the IBCF performs transit routing functions as specified in 3GPP TS 24.229 [5]. 
The IBCF acts as a B2BUA when it performs IMS-ALG functionaUty. 

5.2.2 Transition Gateway (TrGW) 

According to 3GPP TS 23.002 [3], the TrGW is located at the network borders within the media path and is controlled 
by an IBCF. Forwarding of media streams between IM CN subsystem networks is applied over Izi reference point. 

The TrGW provides functions like network address/port translation and IPv4/IPv6 protocol translation. NAT-PT binds 
addresses in IPv6 network with addresses in IPv4 network and vice versa to provide transparent routing between the 
two IP domains without requiring any changes to end points. NA(P)T-PT provides additional translation of transport 
identifier (TCP and UDP port numbers). The approach is similar to that one described also in 3GPP TS 29.162 [8]. 

Further details are described in 3GPP TS 23.228 [4]. 

6 Control plane interconnection 

6.1 Definition of Inter-IMS Network to Network Interconnection 

6.1 .1 SIP metliods and lieader fields 

6.1.1.1 General 

The functional entity closest to the border of an II-NNI (see reference model in Clause 5) shall provide the capabilities 
specified for that network element in Annex A. 2 of 3GPP TS 24.229 [5] with modifications as described in the 
following sub-clauses. 

6.1.1.2 SIP methods 

3GPP TS 24.229 [5] defines the methods allowing an IBCF to interconnect to an IBCF placed in another IM CN 

subsystem. 

The following SIP methods are supported on the II-NNI as defined in table 6.1. 

The following table is based on Table A. 5 and Table A. 163 of 3GPP TS 24.229 [5] and endorsed for this document: 
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Table 6.1 : Supported SIP methods 



Item 


Method 


Ref. 


ll-NNI 


Sending 


Receiving 


1 


ACK request 


IETF RFC 3261 [13] 


m 


m 


2 


BYE request 


IETF RFC 3261 [13] 


m 


m 


3 


BYE response 


IETF RFC 3261 [13] 


m 


m 


4 


CANCEL request 


IETF RFC 3261 [13] 


m 


m 


5 


CANCEL response 


IETF RFC 3261 [13] 


m 


m 


5A 


INFO request 


IETF RFC 6086 [39] 








5B 


INFO response 


IETF RFC 6086 [39] 








8 


INVITE request 


IETF RFC 3261 [13] 


m 


m 


9 


INVITE response 


IETF RFC 3261 [13] 


m 


m 


9A 


IVIESSAGE request 


IETF RFC 3428 [19] 








9B 


IVIESSAGE response 


IETF RFC 3428 [19] 








10 


NOTIFY request 


IETF RFC 3265 [20] 


c1 


cl 


11 


NOTIFY response 


IETF RFC 3265 [20] 


c1 


cl 


12 


OPTIONS request 


IETF RFC 3261 [13] 


m 


m 


13 


OPTIONS response 


IETF RFC 3261 [13] 


m 


m 


14 


PRACK request 


IETF RFC 3262 [18] 


m 


m 


15 


PRACK response 


IETF RFC 3262 [18] 


m 


m 


15A 


PUBLISH request 


IETF RFC 3903 [21] 


Cl 


c1 


15B 


PUBLISH response 


IETF RFC 3903 [21] 


Cl 


c1 


16 


REFER request 


IETF RFC 3515 [22] 








17 


REFER response 


IETF RFC 3515 [22] 








18 


REGISTER request 


IETF RFC 3261 [13] 


c2 


c2 


19 


REGISTER response 


IETF RFC 3261 [13] 


c2 


c2 


20 


SUBSCRIBE request 


IETF RFC 3265 [20] 


cl 


c1 


21 


SUBSCRIBE response 


IETF RFC 3265 [20] 


cl 


c1 


22 


UPDATE request 


IETF RFC 3311 [23] 


m 


m 


23 


UPDATE response 


IETF RFC 3311 [23] 


m 


m 


c1 : In case of roaming scenario, tlie support of the metliod is m, else o. 
c2: In case of roaming scenario, the support of the method is m, else n/a. 


NOTE: In the above table, m, o and c and n/a have the meanings indicated in Table 6.3 



6.1.1.3 



SIP header fields 



6.1.1.3.0 



General 



The IBCF shall provide the capabilities to manage and modify SIP header fields according to section 5.10 and Annex A 
of 3GPP TS 24.229 [5] with modifications as described in the following sub-clauses. 



6.1.1.3.1 



Trust and no trust relationship 



The IBCF acting as exit point applies the procedures described in clause 5. 10.2 of 3GPP TS 24.229 [5] before 
forwarding the SIP signalling to the IBCF acting as entry point. The IBCF acting as entry point applies the procedures 
described in clause 5.10.3 of 3GPP TS 24.229 [5]. 

Additionally, in case there is no trust relationship between the two IM CN subsystems connected by II-NNI, the IBCF 
acting as exit point applies the procedures described in clause 4.4 of 3GPP TS 24.229 [5], before forwarding the SIP 
signalling to the next IBCF acting as an entry point. The IBCF acting as an entry point applies the procedures described 
in clause 5.10.3 of 3GPP TS 24.229 [5]. 

These procedures may be utilized on a per header field basis to realize overall trust as well as per service level screening 
of header fields. Trust relationships and trust domains may be defined by inter-operator agreements for individual 
services and/or individual SIP header fields. 

The management of the SIP header fields (if present) over II-NNI in case of a presence or not of a trust relationship 
between the two interconnected IM CN subsystems is wrapped up in the following table. 
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Table 6.2: Management of SIP header fields over ll-NNI in presence or not of a trust relationship 



Item 


Header field 


Reference 


Trust relationship 


Not trust relationship 


1 


P-Asserted-ldentity 


IETF RFC 3325 [44] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 5) 


As specified in 3GPP TS 24.229 
[5], clause 4.4 
(NOTE 5) 


2 


P-Access-Network- 
Info 


IETF RFC 3455 [24] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


3 


Resource-Priority 


IETF RFC 4412 [78] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


4 


History-Info 


IETF RFC 4244 [25] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in Clause 4.3.3 of 
RFC 4244 [25] and in 3GPP TS 
24.229 [5], clause 4.4 


5 


P-Asserted-Service 


draft-drage-sipping- 

service-identification 

[26] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 3) 


As specified in 3GPP TS 24.229 
[5], clause 4.4 
(NOTE 3) 


6 


P-Charging-Vector 


IETF RFC 3455 [24] 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


7 


P-Charging- 
Function-Addresses 
(NOTE 4) 


IETF RFC 3455 [24] 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


8 


P-Profile-Key 
(NOTE 2) 


IETF RFC 5002 [64] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


9 


P-Private-Networl<- 

Indication 

(N0TE1) 


draft-vanelburg- 
sipping-private- 
network-indication 
[84] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


10 


P-Served-User 
(NOTE 1 , NOTE 2) 


IETF RFC 5502 [85] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


11 


Reason (in a 
response) 


IETF RFC 6432[49] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


12 


P-Early-IVIedia 


IETF RFC 5009 [74] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


N0TE1 
NOTE 2 

note: 

NOTE^ 
NOTE 5 


: For a roaming ll-NNI, a trust relationship with respect to this header field is required. 
I. This header field is only applicable on a roaming ll-NNI. 
S: In addition, value-dependent operator policies may be applied. 
1: This header field is not applicable at ll-NNI. 

i: The handling of the URI parameters "cpc" and "oil", defined in 3GPP TS 24.229 [5] subclause 7.2A.12, is 
specified in 3GPP TS 24.229 [5], clause 4.4. 



6.1.1.3.2 



Derivation of applicable SIP header fields from 3GPP TS 24.229 [5] 



For any method in Table 6.1, the SIP header fields applicable on the II-NNI are detailed in the corresponding method 
tables for the UA role and proxy role sending behaviour in Annex A of 3GPP TS 24.229 [5]. Unless other information 
is specified in the normative part of the present specification, the applicability of header fields at the II-NNI can be 
derived for each method from the corresponding tables in Annex A of 3GPP TS 24.229 [5] as follows: 

All header fields not present in the corresponding tables in Annex A of 3GPP TS 24.229 or marked as "n/a" in 
both the "RFC status" and "profile status" columns for the UA role and proxy role sending behaviour of that 
tables are not applicable at the II-NNI. 

NOTE 1 : Operators could choose to apply header fields for new SIP extensions on an II-NNI based on bilateral 
agreements, but this is outside the scope of the present specification. 

All header fields which are marked as "o" in at least one of the "RFC status" or the "profile status" profile 
columns for the sending behaviour in the corresponding UA role and proxy role tables in Annex A of 3GPP TS 
24.229 [5] and as "n/a" or "o" in the other such columns are applicable at II-NNI based on bilateral agreement 
between operators. 
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All header fields which are marked as "m" in at least one of the "RFC status" or the "profile status" columns for 
the sending behaviour in the corresponding UA role or proxy role table in Annex A of 3GPP TS 24.229 [5] and 
as "n/a", "o", or "m" in the other such columns are applicable at the II-NNI. 

- If conditions are specified, they are also appUcable at the II-NNI and the above rules are applicable to the "n/a", 
"o" and "m" values within the conditions. 

NOTE 2: In the above rules, the RFC profile columns are taken into account in order to enable interworking with 
non-3GPP networks. 

An informative summary of SIP header fields to be used over the II-NNI is proposed in Annex A. 

6.1 .1 .3.3 Applicability of SIP header fields on a roaming II-NNI 

The following SIP header fields are only applicable on a roaming II-NNI: 
Authentication-Info 
Authorization 

- P-Associated-URI 

- P-Called-Party-ID 
P-Preferred-Service 

- P-Profile-Key 
P-Served-User 

- P-Visited-Network-ID 

- Path 

Proxy- Authenticate 
Proxy- Authorization 
Service-Route 

- www-Authenticate 

6.1 .1 .3.4 Applicability of SIP header fields on a non-roaming II-NNI 
Void 

6.1.1.4 Notations of the codes 

In the table 6.1 the status codes "m", "o", "c" and "n/a" have the following meanings: 
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Table 6.3: Key to notation codes for SIP messages 



Notation 
code 


Notation name 


Sending side 


Receiving side 


m 


mandatory 


The message shall be supported at II- 
NNI. 

Supporting sending a SIP message at 
the ll-NNI means that this message shall 
be sent over the ll-NNI if received from 
the serving network. It does not imply 
that network elements inside the serving 
network or user equipment connected to 
this network shall support this message. 


Supporting receiving a SIP message at 
the ll-NNI means that this message shall 
be forwarded to the serving network 
unless the operator's policy is applied as 
defined in subclause 5.10.1 of 
3GPP TS 24.229 [5]. It does not imply that 
network elements inside the served 
network or user equipment connected to 
this network are supporting this message. 





optional 


The message may or may not be 
supported at ll-NNI. The support of the 
message is provided based on bilateral 
agreement between the operators. 


Same as for sending side. 


n/a 


not applicable 


It is impossible to use/support the 
message. 


It is impossible to use/support the 
message. This message will be discarded 
bythelBCF. 


c 
<integer> 


conditional 


The requirement on the message ("m", 
"o" or "n/a") depends on the support of 
other optional or conditional items. 
<integer> is the identifier of the 
conditional expression. 


Same as for sending side. 



6.1.1.5 



Modes of signalling 



Overlap signalling may be used if agreement exists between operators to use overlap and which method to be used, 
otherwise enbloc shall be used at the II-NNI. 



6.1.2 SDP protocol 



6.1.2.1 



General 



The functional entity closest to the border of an II-NNI (see reference model in Clause 5) shall provide the capabilities 
specified for that network element in Annex A. 3 of 3GPP TS 24.229 [5]. 

6.1.3 Major capabilities 

This subclause contains the major capabilities to be supported over the II-NNI. 

The table 6.1.3.1 specifies which capabilities are applicable for II-NNI. The profile status codes within table 6.1.3.1 are 
defined in table 6.1.3.2. 

For the "Basic SIP" capabilities part of table 6.1.3.1, the last column "Profile status over II-NNI" specifies the general 
status of applicability of the IETF RFC 3261 [13] main mechanisms described in the 2"** column "Capability over the 
Ici". 

For the "Extensions to basic SIP" capabilities part, the last column "Profile status over II-NNI" specifies the general 
status of applicability of the RFC referenced in the 2"** column "Capability over the Ici". 

If necessary, the applicability of RFCs at the II-NNI level is further detailed in the present Technical Specification. 

The columns "Reference item in 3GPP TS 24.229 [5] for the profile status" provide informative references for 
comparison purposes into the UA and Proxy role major capabilities tables in 3GPP TS 24.229 [5], where the 
capabilities are defined via additional references. 
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Table 6.1.3.1 : Major capabilities over ll-NNI 



Item 


Capability over the lei 


Reference item in 3GPP 

TS 24.229 [5] for the 

profile status 


Profile 

status over 

ll-NNI 


UA Role 
(N0TE1) 


Proxy role 
(NOTE 2) 




Basic SIP (IETF RFC 3261 [13]) 








1 


registrations 


1,2, 2A 


- 


c2 


2 


initiating a session 


2B, 2C, 3, 4 


- 


m 


3 


terminating a session 


5 


3 


m 


4 


General proxy beliaviour 


- 


4,5, 14, 15, 
19F 


n/a 


5 


IVIanaging several responses due to forking 


9,10 


6 


m 


6 


support of indication of TLS connections in the Record-Route 
header 


- 


7,8 


n/a 


7 


Support of authentication 


7, 8, 8A 


8A 


c2 


8 


Timestamped requests (Timestamp header field) 


6 


- 


m 


9 


Presence of date in requests and responses (Date header 
field) 


11 


9 


m 


10 


Presence of alerting information data (Alert-info header field) 


12 


10 





11 


Support and handling of the Require header field for 
REGISTER and other requests or responses for methods 
other than REGISTER 




11, 12, 13 


m 


12 


Support and reading of the Supported and Unsupported 
header fields 


- 


16, 17, 18 


m 


13 


Support of the Error-Info header field in 3xx - 6xx responses 


- 


19 





14 


Support and handling of the Organization header field 


- 


19A, 19B 


m 


15 


Support and handling of the Call-Info header field 


- 


19C, 19D 


m 


16 


Support of the Contact header field in 3xx response 


- 


19E 


m 




Extensions to basic SIP 








17 


IETF RFC 6086 [39]: SIP INFO method and package 
framework 


13 


20 





17A 


IETF RFC 6086 [39]: legacy INFO usage 


13A 


20A 





18 


IETF RFC 3262 [18]: reliability of provisional responses in 
SIP (PRACK method) 


14 


21 


m 


19 


IETF RFC 3515 [22]: the SIP REFER method 


15 


22 





20 


IETF RFC 3312 [40] and RFC 4032 [41]: integration of 
resource management and SIP (Preconditions framework) 


16 


23 





21 


IETF RFC 331 1 [23]: the SIP UPDATE method 


17 


24 


m 


22 


IETF RFC 3313 [42]: SIP extensions for media authorization 
(P-Media-Authorization header field) 


19 


26 


n/a 


23 


IETF RFC 3265 [20]: SIP specific event notification 
(SUBSCRIBE/NOTIFY methods) 


20,21,22, 
23 


27,28 


Cl 


24 


IETF RFC 3327 [43]: session initiation protocol extension 
header field for registering non-adjacent contacts (Path 
header field) 


24 


29 


c2 


25 


IETF RFC 3325 [44]: private extensions to the Session 
Initiation Protocol (SIP) for network asserted identity within 
trusted networks 


25 


30 


c4 


26 


IETF RFC 3325 [44]: the P-Preferred-ldentity header field 
extension 


- 


- 


n/a 


27 


IETF RFC 3325 [44]: the P-Asserted-ldentity header field 
extension 


- 


- 


c4 


28 


IETF RFC 3323 [34]: a privacy mechanism for the Session 
Initiation Protocol (SIP) (Privacy header field) 


26, 26A, 
26B, 26C, 
26D, 26E, 
26F, 26G, 
26H 


31,31A, 
31B, 31C, 
31D, 31E, 
31F, 31G, 
31H 


m 


29 


IETF RFC 3428 [19]: a messaging mechanism for the 
Session Initiation Protocol (SIP) (MESSAGE method) 


27 


33 





30 


IETF RFC 3608 [45]: session initiation protocol extension 
header field for service route discovery during registration 
(Service-Route header field) 


28 


32 


c2 


31 


IETF RFC 3486 [46]: compressing the session initiation 
protocol 


29 


34 


n/a 


32 


IETF RFC 3455 [24]: private header extensions to the 


30 


35 
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session initiation protocol for tine 3rd-Generation Partnersliip 
Project {3GPP) 








32A 


IETF RFC 3325 [44]: act as first entity within tlie trust domain 
for asserted identity 


30A 


30A 


n/a 


32B 


IETF RFC 3325 [44]: act as entity within trust network that 
can route outside the trust network 


30B 


30B 


n/a 


32C 


IETF RFC 3325: act as entity passing on identity 
transparently independent of trust domain 


30C 


30C 


n/a 


33 


IETF RFC 3455 [24]: the P-Associated-URI header field 
extension 


31 


36 


c2 


34 


IETF RFC 3455 [24]: the P-Called-Party-ID header field 
extension 


32 


37 


c2 


35 


IETF RFC 3455 [24]: the P-Visited-Network-ID header field 
extension 


33 


38,39 


c2 


36 


IETF RFC 3455 [24]: the P-Access-Network-lnfo header field 
extension 


34 


41,42,43 


c4 


37 


IETF RFC 3455 [24]: the P-Charging-Function-Addresses 
header field extension 


35 


44, 44A 


n/a 


38 


IETF RFC 3455 [24]: the P-Charging-Vector header field 
extension 


36 


45,46 


c1 


39 


IETF RFC 3329 [47]: security mechanism agreement for the 
session initiation protocol 


37 


47 


n/a 


39A 


draft-dawes-dispatch-mediasec-parameter [134]: Capability 
Exchange for Media Plane Security 


37A 


47A 


n/a 


40 


IETF RFC 3326 [48]: the Reason header field for the session 
initiation protocol 


38 


48 





41 


IETF RFC 6432 [49]: carrying Q.850 codes in reason header 
fields in SIP (Session Initiation Protocol) responses 


38A 


48A 


c4 


42 


IETF RFC 3581 [50]: an extension to the session initiation 
protocol for symmetric response routeing 


39 


49 





43 


IETF RFC 3841 [51]: caller preferences for the session 
initiation protocol (Accept-Contact, Reject-Contact and 
Request-Disposition header fields) 


40, 40A, 
40B, 40C, 
40D, 40E, 
40 F 


50, 50A, 
50B, 50C, 
50D, 50E, 
50F 


m 


44 


IETF RFC 3903 [21]: an event state publication extension to 
the session initiation protocol (PUBLISH method) 


41 


51 


c1 


45 


IETF RFC 4028 [52]: SIP session timer (Session-Expires and 
IVIin-SE headers) 


42 


52 


m 


46 


IETF RFC 3892 [53]: the SIP Referred-By mechanism 


43 


53 


m 


47 


IETF RFC 3891 [54]: the Session Initiation Protocol (SIP) 
"Replaces" header 


44 


54 





48 


IETF RFC 391 1 [55]: the Session Initiation Protocol (SIP) 
"Join" header 


45 


55 





49 


IETF RFC 3840 [56]: the callee capabilities 


46 


56 





50 


IETF RFC 4244 [25]: an extension to the session initiation 
protocol for request history information (History-Info header 
field) 


47 


57 





51 


IETF RFC 5079 [57]: Rejecting anonymous requests in the 
session initiation protocol 


48 


58 





52 


IETF RFC 4458 [58]: session initiation protocol URIs for 
applications such as voicemail and interactive voice 
response (NOTE 3) 


49 


59 





53 


IETF RFC 4320 [59]: Session Initiation Protocol's (SIP) non- 
INVITE transactions 


50 


61 


m 


54 


IETF RFC 4457 [60]: the P-User-Database private header 
field extension 


51 


60 


n/a 


55 


IETF RFC 5031 [61]: a uniform resource name for services 


52 


62 


n/a 


56 


IETF RFC 5627 [62]: obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


53 


63 


c1 




Void 








58 


IETF RFC 4168 [27]: the Stream Control Transmission 
Protocol (SCTP) as a Transport for the Session Initiation 
Protocol (SIP) 


55 


65 





59 


IETF RFC 5002 [64]: the SIP P-Profile-Key private header 
field extension 


56 


66, 66A, 
66B 


c3 


60 


IETF RFC 5626 [65]: managing client initiated connections in 
SIP 


57 


67 


c1 
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61 


IETF RFC 5768 [66]: indicating support for interactive 
connectivity establishment in SIP 


58 


- 


n/a 


62 


IETF RFC 5365 [67]: multiple-recipient MESSAGE requests 
in the session initiation protocol 


59 


69 


if 29, else 
n/a 


63 


IETF RFC 6442 [68]: Location Conveyance for the Session 
Initiation Protocol 


60 


70, 70A, 
708 


m 


64 


IETF RFC 5368 [69]: referring to multiple resources in the 
session initiation protocol 


61 


71 


if 19, else 
n/a 


65 


IETF RFC 5366 [70]: conference establishment using 
request-contained lists in the session initiation protocol 


62 


72 





66 


IETF RFC 5367 [71]: subscriptions to request-contained 
resource lists in the session initiation protocol 


63 


73 


if 23, else 
n/a 


67 


IETF RFC 4967 [72]: dialstring parameter for the session 
initiation protocol uniform resource identifier 


64 


74 


c2 


68 


IETF RFC 4964 [73]: the P-Answer-State header extension 
to the session initiation protocol for the open mobile alliance 
push to talk over cellular 


65 


75 





69 


IETF RFC 5009 [74]: the SIP P-Early-Media private header 
field extension for authorization of early media 


66 


76 


c4 


70 


IETF RFC 4694 [75]: number portability parameters for the 
"tel" URI 


67, 67A, 
678 


77, 77A, 
77B 





72 


IETF RFC 441 1 [77]: extending the session initiation protocol 
Reason header for preemption events 


69 


79 





73 


IETF RFC 4412 [78]: communications resource priority for 
the session initiation protocol (Resource-Priority header field) 


70, 70A, 
70B 


80, 80A, 
80B 





74 


IETF RFC 5393 [79]: addressing an amplification 
vulnerability in session initiation protocol forking proxies 


71 


81 


m 


75 


IETF RFC 5049 [80]: the remote application identification of 
applying signalling compression to SIP 


72 


82 


n/a 


76 


IETF RFC 5688 [81]: a session initiation protocol media 
feature tag for IVIIME application sub-types 


73 


83 


Cl 


77 


IETF RFC 6050 [26]: Identification of communication 
services in the session initiation protocol 


74 


84, 84A 





78 


IETF RFC 5360 [82]: a framework for consent-based 
communications in SIP 


75, 75A, 
75B 


85 





79 


draft-ietf-cuss-sip-uui [83]: a mechanism for transporting user 
to user call control information in SIP 


76 


86 


cl 


79A 


draft-ietf-cuss-sip-uui-isdn [83A]: Interworking ISDN Call 
Control User Information with SIP 


76A 


n/a 


cl 


80 


draft-vanelburg-dispatch-private-network-ind-01 [84]: The 
SIP P-Private-Network-lndication private-header (P-Header) 


77 


87 


cl 


81 


IETF RFC 5502 [85]: the SIP P-Served-User private header 


78 


88 


c2 


83 


draft-dawes-sipping-debug-04 [87]: the P-Debug-ID header 
extension 


80 


90 





84 


IETF RFC 6228 [88]: the 199 (Early Dialog Terminated) 
response code 


81 


91 


m 


85 


IETF RFC 5621 [89]: message body handling in SIP 


82 


92 


m 


86 


IETF RFC 6223 [90]: indication of support for keep-alive 


83 


93 





87 


IETF RFC 5552 [91]: SIP Interface to VoiceXML Media 
Services 


84 


94 


n/a 


88 


IETF RFC 3862 [92]: common presence and instant 
messaging (CPIM): message format 


85 


95 





89 


IETF RFC 5438 [93]: instant message disposition notification 


86 


96 





90 


IETF RFC 5373 [94]: requesting answering modes for SIP 
(Answer-Mode and Priv-Answer-Mode header fields) 


87 


97, 97A 







Void 








92 


IETF RFC 3959 [96]: the early session disposition type for 
SIP 


89 


99 





93 


IETF RFC 4244 [25]: delivery of Request-URI targets to 
user agents 


90 


100 


n/a 


94 


draft-kaplan-sip-session-id-02 [124]: The Session-ID header 


91 


101 





95 


IETF RFC 6026 [125]: correct transaction handling for 200 
responses to Session Initiation Protocol INVITE requests 


92 


102 


m 


96 


IETF RFC 5658 [126]: addressing Record-Route issues in 
the Session Initiation Protocol (SIP) 


93 


103 





97 


IETF RFC 5954 [127]: essential correction for IPv6 ABNF 
and URI comparison in IETF RFC 3261 [13] 


94 


104 


m 
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98 


IETF RFC 4488 [132]: suppression of session initiation 
protocol REFER method implicit subscription 


95 


105 


c5 


99 


draft-ietf-salud-alert-info-urns [133]: Alert-Info URNs for the 
Session Initiation Protocol 


96 


106 





100 


Subclause 3.1 of 3GPP TS 24.229: multiple registrations 


97 


107 


c2 


101 


IETF RFC 4538 [135]: request authorization through dialog 
Identification in the session initiation protocol (Target-Dialog 
header field) 


99 


109 





c1 : m in case of roaming ll-NNI, else o 

c2: m in case of roaming ll-NNI, else n/a 

c3: in case of roaming ll-NNI, else n/a 

c4: m in case of trust relationship between the interconnected networks, else n/a 

c5: m in the case the REFER request is supported, else n/a 


NOTE 1 : The item numbering corresponds to the one provided in table A.4 in [5] 
NOTE 2: The item numbering corresponds to the one provided in table A. 162 in [5] 
NOTE 3: A common URI namespace is required to apply this feature on the ll-NNI 



Table 6.1.3.2: Key to notation codes for major capabilities 



Notation 
code 


Notation name 


Explanation 


m 


mandatory 


The capability shall be supported at ll-NNI. 

SIP message relating to this capability shall be sent over the ll-NNI if received from 

the serving network, unless they also make use of other unsupported capabilities. 

SIP headers or other information elements relating to this capability shall be passed 

over the ll-NNI if received from the sending side. 

This does not imply that network elements inside the serving network or served 

network or user equipment connected to these networks shall support this capability. 





optional 


The capability may or may not be supported at ll-NNI. The support of the capability is 
provided based on bilateral agreement between the operators. 


n/a 


not applicable 


It is impossible to use/support the capability at the ll-NNI. 


c 
<integer> 


conditional 


The support of the capability ("m", "o" or "n/a") depends on the support of other 
optional or conditional items. <integer> is the identifier of the conditional expression. 



6.2 Control Plane Transport 



6.2.1 General 

The control plane transport of the II-NNI shall comply with Clause 4.2 A of 3GPP TS 24.229 [5]. 

Support of SCTP as specified in IETF RFC 4168 [27] is optional for an IBCF connected by II-NNI. Nevertheless this 
option is favourable if the operators would like to improve reliability over the Ici. 



User plane Interconnection 



7.1 



Media and Codec 



For "end-to-end" media session involving the II-NNI, the SIP/SDP codec negotiation procedure can be applied between 
IM CN subsystems using different media codecs. It is possible that the end-to-end codec negotiation could fail because 
no common codec could be supported by the UEs, in particular for voice services. 

To enhance interoperability, the IBCF, the MRFC, or other IMS network entities can interfere with the end-to-end 
codec negotiation to offer additional codec(s) available via transcoding, or to remove codecs. The IBCF can configure 
an attached TrGW to transcode, and the MRFC can configure an attached MRFP to transcode. 

Codecs applicable at the NNI may be a subject of interworking agreements. 
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NOTE: Possible codecs which could be used at the II-NNI are described in 3GPP TS 26. 1 14 [ 1 1 ] and ETSI TS 

181 005 [12]. 

However, to avoid that transcoding is performed several times, applicable codecs at the NNI should be restricted as 
little as possible. 

NOTE: Transcoding can be performed in an IMS network serving an SDP offerer or in an IMS network serving 
an SDP answerer. To avoid that transcoding is performed multiple times, inter-operator agreements can 
clarify if it is preferred that IMS network serving an SDP offerer or IMS network serving an SDP 
answerer modify an SDP offer to offer transcoding. 

If the IBCF performs media transcoding control, it shall apply the related procedures in 3GPP TS 24.229 [5]. 

7.2 User Plane Transport 

The user plane transport of the II-NNI may use the protocols listed in Table 7.2.1. The used protocols to transport media 
are negotiated by means of SDP offer/answer. 

Table 7.2.1 : Supported transport-level RFCs to be described in SIP/SDP messages 



Item 


RFC 


Title 


Support 


1 


IETF RFC 3550 [137] 


RTP: A Transport Protocol for Real-Time Applications 


Mandatory 


2 


IETF RFC 768 [138] 


User Datagram Protocol 


Mandatory 


3 


IETF RFC 3551 [139] 


RTP Profile for Audio and Video Conferences with Minimal Control 


Mandatory 


4 


IETF RFC 3556 [140] 


Session Description Protocol (SDP) Bandwidth Modifiers for RTP 
Control Protocol (RTCP) Bandwidth 


Mandatory 


5 


IETF RFC 4585 [141] 


Extended RTP Profile for Real-time Transport Control Protocol 
(RTCP) - Based Feedback (RTP/AVPF) 


Optional 
(N0TE1) 


6 


IETF RFC 793 [142] 


Transmission Control Protocol 


Optional 
(NOTE 2) 


NOTE 1: used by MTSI, as indicated in 3GPP TS 26.114 [11] 
NOTE 2: used for MSRP service 





8 Numbering, Naming and Addressing 

8.1 Numbering, Naming and Addressing for SIP message 

The following URI formats in SIP messages may be applied at the Ici as standardized in 3GPP TS 24.229 [5]: 

• SIP URI defined in IETF RFC 326 1 [ 1 3] ; 

• tel URI defined in IETF RFC 3966 [ 14] ; 

• IM URI defined in IETF RFC 3860 [15]; 

• PRES URI defined in IETF RFC 3859 [16]. 

According to 3GPP TS 24.229 [5], the IBCF acting as an exit or entry point in the IMS network supports these URI 
formats. These URI formats shall be supported at the roaming II-NNI. The SIP URI format shall be supported at the 
non-roaming II-NNI. The tel URI, IM URI and PRES URI formats may be supported at the non-roaming II-NNI based 
on agreement between operators. Other URI formats may be supported over the II-NNI depending on the operator 
agreements. 

A global number as defined in IETF RFC 3966 [14] shall be used in a tel URI or in the user portion of a SIP URI with 
the user=phone parameter when conveyed via a non-roaming II-NNI in the Request-URI and in the P-Asserted-Identity 
header field, except when agreement exists between the operators to also allow other kinds of numbers. 

NOTE 1 : In a SIP URI the user portion of the Request-URI represents a telephone number only if the SIP URI 
includes the user=phone parameter. 
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NOTE 2: Agreements can exist between operators to allow non-global number (e.g. national service numbers. 

business trunking numbers, or private numbers) at a non-roaming II-NNI. A SIP URI with such a number, 
a user=phone parameter, and a phone-context parameter agreed between the operators can then be used. 

NOTE 3: 3GPP TS 24.229 [5] allows to restrict the number within a SIP Request-URI with user=phone parameter 
at a non-roaming II-NNI to be a global number (i.e. E.164 in international format) via an appropriate 
Application Server. Suitable configuration by the operator is needed to achieve the desired modification 
of the format. 

NOTE 4: The allowed phone number formats in the P-Asserted-Identity header field of a served user are configured 
by the operator. According to 3GPP TS 23.003 [35], international E.164 format is used within a P- 
Asserted-Identity header field. 

NOTE 5: The global number format usage within a SIP Request-URI with the user=phone parameter at a non- 
roaming II-NNI allows the terminating network to find the called subscriber, via HSS interrogation, 
without any further number translation and thus improves the success of the interconnection between IMS 
operators. 

The optional "oli" and "cpc" tel URI parameters associated with a tel URI or a SIP URI with user=phone are described 
in 3GPP TS 24.229 [5] and can be part of the P-Asserted-Identity header field. Depending on operator agreements, 
those URI parameters may be supported at the non-roaming II-NNI. 

The "sos" SIP URI parameter associated with a URI in the Contact header field of a REGISTER request or 200 OK 
response to REGISTER request is described in 3GPP TS 24.229 [5]. The "sos" SIP URI parameter shall be supported at 
the roaming II-NNI. 

The "rn" and "npdi" number portability parameters for the tel URI and the SIP URI with user=phone as described 
within IETF RFC 4694 [75] can be part of the Request-URI. Depending on operator agreements these parameters may 
be exchanged over the non-roaming II-NNI. 

NOTE 6: The "rn" and "npdi" parameters can be used to address the entry point of the terminating operator 
depending on national rules for number portability. 

The "isub" tel URI parameter for the tel URI and the SIP URI with user=phone as described within 

IETF RFC 3966 [14] can be part of the Request-URI, To header field and P-Asserted-Identity header field. Depending 

on operator agreements, this URI parameter may be exchanged over the II-NNI. 

8.2 Numbering, Naming and Addressing for SDP 

The following URI format in the SDP exchange may be applied at the Ici as standardized in 3GPP TS 24.229 [5]: 

• MSRP URI for a session of instant messages defined in IETF RFC 4975 [17]. 

This URI format shall be supported at the roaming II-NNI and may be supported at the non-roaming II-NNI based on 
agreement between operators. Other URI formats may be supported over the II-NNI depending on the operators' 
agreements. 



IP Version 



The network elements interconnected by means of the II-NNI may support IPv4 only, IPv6 only or both. 

The support of one or both of the IP versions is an operator option and should be based on bilateral agreement. 

In case IPv4 and IPv6 networks are interconnected, the involved IBCFs and TrGWs shall apply the IP version 
interworking procedures as indicated in 3GPP TS 29.162 [8]. 



10 Security 



The supported security mechanisms for IP signalling transport over II-NNI interfaces are described in 3GPP TS 33.210 
[10]. 
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1 1 Charging 



The accounting information to be supported over the Ici is described in 3GPP TS 32.260 [29]. It shall be configurable 
by the operator to use or not the accounting mechanisms provided by the IBCF. 



12 Supplementary services associated with the IIVIS 
multimedia telephony communication service 

12.1 General 

In order to assure the end-to-end service interoperability through the Inter-IMS Network to Network Interface (II-NNI), 
the associated supplementary services of the multimedia telephony communication service may be supported on the II- 
NNI between the two IMS networks. 

The MMTel communication service is identified by means of the media feature tag H-g.3gpp.icsi-ref set to "urn:urn- 
7:3gpp-service.ims.icsi.mmtel". The media feature tag can appear in the Contact header field, the Accept-Contact 
header field and the P-Asserted-Service header field. 

The support of each associated supplementary service is based on agreement between operators. 

If a supplementary service is supported, the related procedures from the 3GPP TS 22.173 [30], the protocol details from 
the 3GPP TS 24.173 [31] and specifications referenced in the later specification shall be applied with the requirements 
in the relevant subclause due to the crossing of the II-NNI. 

12.2 Malicious Communication IDentification (MCID) 

Service specific requirements in accordance with 3GPP TS 24.616 [33] shall be supported over the II-NNI. 

The P-Asserted-Identity header field shall be supported at the II-NNI. 

The INFO request and the 200 (OK) response to the INFO request containing the "application/vnd.etsi.mcid-nxml" 
MIME body defined in 3GPP TS 24.616 [33] may be supported at the II-NNI. 

If a network terminating the dialog supports MCID, the terminating network shall only deliver the MCID request in the" 
application/ mcid-nxm 1 " MIME body, as specified in the 3GPP TS 24.616 [33], if an agreement to use the MCID 
supplementary service according to the 3GPP TS 24.616 [33] exists with the network originating the dialog and if the 
INVITE request received by the terminating network does not contain the information of the originating party. 

NOTE: The IBCF and the AS in the terminating network interact to deliver the MCID request only if an 

agreement to use the MCID supplementary service exists, as specified in 3GPP TS 24.616 [33] and 3GPP 
TS 24.229 [5]. 

The originating network and the terminating network shall have a bilateral agreement to support transportation of the 
minimum information specified in subclause 4.5.2.5.0 of the 3GPP TS 24.616 [33] between the networks. 

12.3 Originating Identification Presentation (OIP) and Originating 
Identification Restriction (OIR) 

Service specific requirements in accordance with 3GPP TS 24.607 [32] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and 
"critical" shall be supported at the II-NNI. 
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NOTE 1 : P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields 

will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, this header field cannot be altered 
when passing through the II-NNI according to 3GPP TS 24.229 [5]. Where no trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, the P-Asserted-Identity header field 
will be removed by the IBCF of the originating network prior passing through the II-NNI according to the 
3GPP TS 24.229 [5]. The IBCF determines whether to remove the P-Asserted-Identity header field 
according to procedures in 3GPP TS 24.229 [5] clause 4.4.2 referencing IETF RFC 3325 [44]. 

The option tag "from-change" in the Supported header field should be supported at II-NNI. 

NOTE 2: The From header field cannot be altered when passing through the II-NNI and will be passed 

transparently by the IBCF. If a request is received by the terminating network and the application of the 
OIR service is required with the value "user" for the Privacy header field then the From header field will 
be anonymised in accordance with IETF RFC 3323 [34] by the terminating network. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.4 Terminating Identification Presentation (TIP) and 
Terminating Identification Restriction (TIR) 

Service specific requirements in accordance with 3GPP TS 24.608 [113] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and 
"critical" shall be supported at the II-NNI. 

NOTE: P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields 

will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, this header field cannot be altered 
when passing through the II-NNI according to 3GPP TS 24.229 [5]. 

Where no trust relationship exists on the P-Asserted-Identity header field between the two IMS networks, 
the P-Asserted-Identity header field will be removed by the IBCF of the originating network prior passing 
through the II-NNI according to the 3GPP TS 24.229 [5]. The IBCF determines whether to remove the P- 
Asserted-Identity header field according to procedures in 3GPP TS 24.229 [5] clause 4.4.2 referencing 
IETF RFC 3325 [44]. 

The option tag "from-change" defined in IETF RFC 4916 [143], in the Supported header field should be supported at II- 
NNI. 

12.5 Anonymous Communication Rejection (ACR) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field shall be supported at the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 433 (Anonymity Disallowed) shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.6 Communication Diversion (CDIV) 

Service specific requirements in accordance with 3GPP TS 24.604 [117] shall be supported over the II-NNI. 

NOTE 1 : The support of the Diversion header field not adopted in 3GPP TS 24.604 requires bilateral agreement 
between the operators. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 
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The Privacy header field with value "history" shall be supported at the II-NNI. 

The History-Info header field as described by 3GPP TS 24.604 [117] and the Cause-Codes as defined by the 
IETF RFC 4458 [58] shall be supported over the II-NNI. 

NOTE 2: The networks can have an internal limit in the number of allowed diversions, as described in 3GPP TS 

24.604 [117], section 4.5.2.6. 1 . To ensure efficiency of this control operators can indicate in their bilateral 
agreements their own number of allowed communication diversions, the parameter that is used for 
counting, and the network behavior when the internal limit is reached. 

The response code 181 (Call Is Being Forwarded) shall be supported at the II-NNI. 

The SUBSCRIBE requests with the event package name "comm-div-info" and the NOTIFY request procedure as 
specified in IETF RFC 3265 [20] and 3GPP TS 24.229 [5] shall be supported at the roaming II-NNI if CDIVN is 
provided. 

The MESSAGE request procedure as specified in IETF RFC 3428 [19] and 3GPP TS 24.229 [5] should be supported at 
the roaming II-NNI if CDIVN is provided. 

NOTE 3: The content of the MESSAGE request is operator specific. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.7 Communication Waiting (CW) 

Service specific requirements in accordance with 3GPP TS 24.615 [37] shall be supported over the II-NNI. 

The 'appHcation/vnd.3gpp.cwH-xmr MIME body defined in 3GPP TS 24.615 [37] in the INVITE request shall be 
supported at the roaming II-NNI. 

The Alert-Info header field set to "urn:alert:service:call-waiting" in a 180 (Ringing) response shall be supported at the 
II-NNI. 

As a network option, in case of expiry of the CW timer, the response code 480 (Temporarily Unavailable) including a 
Reason header field set to cause 19 shall be supported at the non-roaming II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

12.8 Communication HOLD (HOLD) 

Service specific requirements in accordance with 3GPP TS 24.610 [36] shall be supported over the II-NNI. 

NOTE: The support of an alternative method not adopted in 3GPP TS 24.610 requires bilateral agreement 
between the operators and is outside the scope of the present document. 

Procedures as described in subclause 12.21.3 are used to provide announcements. 

12.9 IVIessage Waiting Indication (IVIWI) 

Service specific requirements in accordance with 3GPP TS 24.606 [112] shall be supported over the II-NNI. 

The event package name "message-summary" according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] in the 
SUBSCRIBE request shall be supported at the roaming II-NNI. 

The application/simple-message-summary-Hxml MIME body described in 3GPP TS 24.606 [1 12] in the NOTIFY 
request shall be supported at the roaming II-NNI. 
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12.10 Communication Barring (CB) 

12.10.1 Incoming Communication Barring (ICB) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header field as described in 3GPP TS 24.61 1 [1 14] shall be 
supported at the II-NNI. 

A Reason header field as described in 3GPP TS 24.61 1 [1 14] included in the BYE request shall be supported at the II- 
NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.10.2 Outgoing Communication Barring (OCB) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header field as described in 3GPP TS 24.61 1 [1 14] shall be 
supported at the roaming II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.1 1 Completion of Communications to Busy Subscriber (CCBS) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the II-NNI. 

The response code 486 (Busy Here) containing a Call-Info header field with a "purpose" header field parameter set to 
"call-completion" and the "m" parameter set to "BS" shall be supported at the non-roaming 11-NNl. 

For invoking and revoking of the CCBS supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI. 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shall be supported at the roaming II-NNI. 

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [38] should be 
supported at the roaming 11-NNl. 

NOTE 1 : 3"* party call control procedures can be used when the REFER request is not supported at the II-NNI. 

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5]. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" and the Call-Info header field with a purpose parameter set to 'call-completion' 
and the m parameter set to "BS" shall be supported at the non-roaming II-NNI. 

The Request-URI with the "m" SIP URI parameter with a value set to "BS" and the Call-Info header field with a 
purpose parameter set to 'call-completion' and the "m" parameter set to "BS" in the INVITE method shall be supported 
at the non-roaming II-NNI. 

The Date header field in the 486 (Busy Here) response to the INVITE request shall be supported at the roaming 11-NNl. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 
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12.12 Completion of Communications by No Reply (CCNR) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the Il-NNI. 

The response code 180 (Ringing) containing a Call-Info header field with a purpose parameter set to 'call-completion' 
and the "m" parameter set to "NR" shall be supported at the non-roaming 11-NNl. 

For invoking and revoking of the CCNR supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
II-NNl. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNL 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shall be supported at the roaming II-NNL 

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [38] should be 
supported at the roaming II-NNL 

NOTE 1 : 3rd party call control procedures can be used when the REFER request is not supported at the II-NNL 

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5]. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" and the Call-Info header field with a purpose parameter set to 'call-completion' 
and the m parameter set to "NR" shall be supported at the non-roaming II-NNL 

The Request-URI with the "m" SIP URI parameter with a value set to "NR" and the Call-Info header field with a 
purpose parameter set to 'call-completion' and the "m" parameter set to "NR" in the INVITE method shall be supported 
at the non-roaming II-NNL 

The Date header field in the 480 (Temporarily Unavailable) response to the INVITE request shall be supported at the 
roaming II-NNL 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNL 

12.13 Explicit Communication Transfer (ECT) 

Service specific requirements in accordance with 3GPP TS 24.629 [1 16] shall be supported over the II-NNL 

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] 
and the NOTIFY method containing an " application/sipfrag " MIME body shall be supported at the II-NNI for call 
transfer without third party call control. 

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] 
and the NOTIFY method containing an " application/sipfrag " MIME body shall be supported at the roaming II-NNI for 
call transfer with third party call control. 

The Refer-To URI header parameter in the REFER request containing the Require header field set to "replaces" shall be 
supported at the roaming II-NNL 

The Replaces header field in the INVITE request shall be supported at the non-roaming II-NNI. 

12.14 Customized Alerting Tone (CAT) 

Service specific requirements in accordance with 3GPP TS 24.182 [129] shall be supported over the II-NNI. 

The P-Early -Media header field in as described in 3GPP TS 24.182 [129] shall be supported at the II-NNI. 

The response code 183 (Session Progress) including a P-Early-Media header field shall be supported over the II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported over the II-NNI. 
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The Supported header field and the Require header field with "early-session" option-tag may be supported at the II- 

NNI. 

An " application/sdp " MIME body with the Content-Disposition set to "early-session" as specified in IETF RFC 3959 
[96] may be supported at II-NNI. 

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] may be supported at the II-NNI. 

NOTE 1 : For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the 
control plane. 

NOTE 2: Multiple methods for DTMF transport are defined in 3GPP TS 24.182 [129]. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.15 Customized Ringing Signal (CRS) 

Service specific requirements in accordance with 3GPP TS 24.183 [98] shall be supported over the II-NNI. 

An Alert-Info header field in the initial INVITE request containing an URI followed by a URN "urn:alert:service:crs" 
shall be supported at the II-NNI. 

A Contact header field in the initial INVITE request containing a "g.3gpp.crs" feature tag may be supported at the II- 
NNI. 

The Supported header field and the Require header field with "early-session" option-tag may be supported at the II- 
NNI. 

An " application/sdp " MIME body with the Content- Disposition set to "early-session" as specified in IETF RFC 3959 
[96] may be supported at II-NNI. 

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] may be supported at the II-NNI. 

NOTE: For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the 
control plane. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.16 Closed User Group (CUG) 

Service specific requirements in accordance with 3GPP TS 24.654 [103] shall be supported over the II-NNI. 

The "application/vnd.etsi.cug-Hxml" MIME body as specified 3GPP TS 24.654 [103] shall be supported in INVITE 
requests at the II-NNI. 

NOTE: If no agreement between the originating network and the terminating network exists to support the CUG 
supplementary service the INVITE request is rejected as described in IETF RFC 5621 [89] when the 
"handling" parameter in the Content-Disposition of the " application/vnd.etsi.cug-nxml" MIME body is set 
to "required". 

The 403 (Forbidden) response, the 603 (Decline) response and the 500 (Server Internal Error) response shall be 
supported at II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.17 Personal Network IVIanagement (PNIVI) 

Service specific requirements in accordance with 3GPP TS 24.259 [99] shall be supported over the II-NNI. 

The Contact header field of the REGISTER request containing the g.3gpp.iari_ref feature tag with the value urn:urn- 
7:3gpp-application.ims.iari.pnm-controller shall be supported at the roaming II-NNI. 
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The Accept-Contact header field containing a g.3gpp.iari_ref feature tag with the value urn:urn-7:3gpp- 
application.ims.iari.pnm-controller shall be supported at the II-NNI. 

The History-Info header field and Supported header field containing the "histinfo" option tag as described by 3GPP TS 
24.259 [99] shall be supported at II-NNI. 

12.18 Three-Party (3PTY) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 

NOTE 1: The requirements below can be relaxed by bilateral agreements between operators. 

The requirements for the 3PTY supplementary service are the same as for the CONF supplementary service specified in 
subclause 12.19 with the following additional requirement: 

If a REFER request is supported at the II-NNI, a Replaces header field in the header portion of the SIP URI of 
the Refer-to header field of the REFER request shall also be supported at II-NNI. 

NOTE 2: Subclause 12.19 describes the conditions for the support of the REFER request. 

12.19 Conference (CONF) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 

NOTE 1 : The requirements below can be relaxed by bilateral agreements between operators. 

The REFER request shall be supported at the roaming II-NNI in the direction from visited to home network. Based on 
inter-operator agreement, the REFER request may be supported at the non-roaming II-NNI, and at the roaming II-NNI 
in the direction from home network to visited network. 

NOTE 2: If the REFER request is not supported at the non-roaming II-NNI, or at the roaming II-NNI in the 

direction from home network to visited network, an attempt of an UE to send the REFER directly to peers 
to invite them to a conference without involvement of the conference focus can fail over such an II-NNI. 
However such failures can also occur if a peer is located in a circuit switched network, or if a peer does 
not support the REFER method. An operator can avoid such failures by configuring an AS to convert the 
REFER to an INVITE, as detailed in 3GPP TS 24.628 [38]. Information on security risks associated with 
the REFER request is provided within the security consideration" of IETF RFC 3515 [22]. 

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5]. 

The application/resource-listsH-xml MIME body shall be supported at the roaming II-NNI. 

The Referred-By header field in the INVITE request shall be supported at the II-NNI. 

The "isfocus" feature parameter indicated in Contact header field of the INVITE request and in the 200 (OK) response 
shall be supported at the II-NNI. 

The SUBSCRIBE request including the "conference" event package name in the Event header field and the NOTIFY 
request procedures according to 3GPP TS 24. 147 [106] shall be supported at the II-NNI. 

The Allow-Events header field with the value "conference" shall be supported at the roaming II-NNI and may be 
supported at the non-roaming II-NNI. 

12.20 Flexible Alerting (FA) 

Service specific requirements in accordance with 3GPP TS 24.239 [101] shall be supported over the II-NNI. 

The 486 (Busy Here) response code shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 
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12.21 Announcements 

12.21.1 General 

Announcements may be provided during the establishment of a communication session or during an estabUshed 
communication session. Both of them shall be managed over the II-NNI. 

1 2.21 .2 Providing announcements during tine establisiiment of a 
communication session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 

The P-Early-Media header authorizing early media as defined in IETF RFC 5009 [74] during the establishment of a 
communication fields shall be supported at the II-NNI. 

The Alert-Info header in the 1 80 (Ringing) response to the INVITE request during the establishment of a 
communication, should be supported at the II-NNI. 

NOTE: The IBCF can decide to remove the Alert-Info header field if required by local policy. 

1 2.21 .3 Providing announcements during an establislned communication 
session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 

In case of provision of an announcement to a user over the II-NNI during an established communication, the Call-Info 
header field in a re-INVITE request should be supported at the II-NNI. 

NOTE 1 : An alternative method to provide announcements is to use the existing media stream. 

NOTE 2: The IBCF can decide to remove the Call-Info header field if required by local policy. 

1 2.21 .4 Providing announcements winen communication request is rejected 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements when a communication request is 
rejected. 

There are three methods defined in 3GPP TS 24.628 [38] to provide the announcement: 

1) sending an announcemt as an early media; 

2) return an Error-Info header field; and 

3) accept the communication request and then provide the announcement. 

NOTE 1 : The II-NNI requirements for accepting the communication request and then provide the announcement is 
not within the scope of this subclause. 

The P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [74] and the Reason header field 
with the proper cause value shall be supported at the II-NNI. 

NOTE 2: There are 2 methods to use early media for sending the announcement in-band. First method is the 

gateway model defined by IETF RFC 3960 [136], second method is described in 3GPP TS 24.628 [38] 
Annex D. 

The Error-Info header field in the 3xx, 4xx, 5xx or 6xx response to the INVITE request when rejecting the 
communication request, should be supported at the II-NNI. 

NOTE 3: The IBCF can decide to remove the Error-Info header field if required by local policy. 
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1 2.22 Advice of Charge (AOC) 

Service specific requirements in accordance with 3GPP TS 24.647 [122] shall be supported over the Il-NNI. 
The Accept header field with "application/vnd.etsi.aoc+xml" shall be supported at the roaming 11-NNI. 

The INVITE method containing an application/vnd.etsi.aoc+xml" MIME body shall be supported at the roaming II- 

NNl. 

Ixx provisional responses and the 200 (OK) response to the initial INVITE request containing an 
application/vnd.etsi.aoc+xml MIME body shall be supported at the roaming II-NNI. 

The INFO method containing an application/vnd.etsi.aoc+xml MIME body shall be supported at the roaming II-NNI. 

The response code 504 (Server Time-out) shall be supported at the II-NNI. 

A Reason header field with a reason value with the protocol set to "SIP" and the cause set to "504" and a reason value 
with the protocol set to "Q.850" and the cause set to "31" in the BYE method shall be supported at the II-NNI. 

An application/vnd.etsi.aoc+xml MIME body in the BYE request or the final response to the BYE request shall be 
supported over the roaming II-NNI. 
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Annex A (informative): 
Summary of SIP header fields 

A summary of the SIP header fields to be used in case of interconnection by using II-NNI is proposed in Table A.l. 

The starting point is the sending behaviour described for proxy and UA roles in Annex A of 3GPP TS 24.229 [5]. In 
case of misalignment between Table A.l and the behaviour described in 3GPP TS 24.229 [5], the behaviour in 3GPP 
TS 24.229 [5] has the precedence. In case a header field is not described in Table A.l and it is described in 3GPP TS 
24.229 [5], the description in 3GPP TS 24.229 [5] is applicable over II-NNI. 

The notation of the codes used for the SIP headers listed in table A. 1 has a different meaning to the one proposed for the 
SIP messages. The definition of these terms is provided in table A.2. 
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Table A.1 : Supported header fields 



Item 


Header field 


Ref. 


ll-NNI 


1 


Accept 


[51 


m 


2 


Accept-Contact 


[51 


m 


3 


Accept-Encoding 


[51 


m 


4 


Accept-Language 


[51 


m 


4a 


Accept-Resource-Priority 


[51 





5 


Alert- Info 


[51 





6 


Allow 


[51 


m 


7 


Allow-Events 


[51 


m on roaming ll-NNI, else o 


8 


Authentication-Info 


[51 


m on roaming ll-NNI, else n/a 


9 


Authorization 


[51 


m on roaming ll-NNI, else n/a 


9a 


Answer-IVIode 


[51 





10 


Call-ID 


[51 


m 


11 


Call-Info 


[51 


m 


12 


Contact 


[51 


m 


13 


Content-Disposition 


[51 


m 


14 


Content-Encoding 


[51 


m 


15 


Content-Language 


[51 


m 


16 


Content-Length 


[51 


m 


17 


Content-Type 


[51 


m 


18 


Cseq 


[51 


m 


19 


Date 


[51 


m 


20 


Error- Info 


[51 





21 


Expires 


[51 


m 


21a 


Flow-Timer 


[51 


m on roaming ll-NNI, else o 


22 


Event 


[51 


m 


23 


From 


[51 


m 


24 


Geolocation 


[51 


m 


24a 


Geolocation-Error 


[51 


m 


24b 


Geolocation-Routing 


[51 


m 


25 


History-Info 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 4) 





25a 


Info- Package 


[51 





26 


In-Reply-To 


[51 





27 


Join 


[51 





27a 


IVIax-Breadth 


[51 


m 


28 


Max-Forwards 


[51 


m 


29 


Min-Expires 


[51 


m 


30 


MIME-Version 


[51 


m 


31 


Min-SE 


[51 


m 


32 


Organization 


[51 


m 


33 


P-Access-Network-lnfo 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 2) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


33a 


P-Answer-state 


[51 





34 


P-Asserted-ldentity 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 1) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


35 


P-Asserted-Service 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 5) 





35a 


P-Associated-URl 


[51 


m on roaming ll-NNI, else n/a 


36 


P-Called-Party-ID 


[51 


m on roaming ll-NNI, else n/a 


37 


P-Charging-Function- 
Addresses 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 7) 


n/a 


38 


P-Charging-Vector 


sub-clause 


m on roaming ll-NNI, else o 
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Item 


Header field 


Ref. 


ll-NNI 






6.1.1.3.1 
(Table 6.2, 
item 6) 




38a 


P-Debug-ld 


[51 





39 


P-Early-Media 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 12) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


40 


P-Media-Authorization 


[5] 


n/a 


41 


P-Preferred-ldentity 


[51 


n/a 


42 


P- Preferred-Service 


[51 


m on roaming ll-NNI, else n/a 


43 


P-Private-Network-lndication 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 9) 


m on roaming ll-NNI, else o 


44 


P-Profile-Key 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 8) 


on roaming ll-NNI, else n/a 


45 


P-Served-User 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 10) 


m on roaming ll-NNI, else n/a 


46 


P-User-Database 


[51 


n/a 


47 


P-Visited-Network-ID 


[51 


m on roaming ll-NNI, else n/a 


47a 


Path 


[51 


m on roaming ll-NNI, else n/a 


47b 


Permission-Missing 


[51 




48 


Priority 


[51 





48a 


Priv-Answer-Mode 


[51 





49 


Privacy 


[51 


m 


50 


Proxy-Authenticate 


[51 


m on roaming ll-NNI, else n/a 


51 


Proxy-Authorization 


[51 


m on roaming ll-NNI , else n/a 


52 


Proxy-Require 


[51 


m 


52a 


RAck 


[51 


m 


53 


Reason 


[51 and sub- 
clause 
6.1.1.3.1 
(Table 6.2, 
item 11) 


when in a request. 

When in a response, m in case of a trust relationship 

between the interconnected networks, else n/a 


54 


Record-Route 


[51 


m 


54a 


Recv-lnfo 


[51 





55 


Referred-By 


[51 


m 


55a 


Refer-Sub 


[51 


m in the case the REFER request is supported, else n/a 


55b 


Refer-To 


[51 


m in the case the REFER request is supported, else n/a 


56 


Reject-Contact 


[51 


m 


57 


Replaces 


[51 





58 


Reply-To 


[51 





59 


Request-Disposition 


[51 


m 


60 


Require 


[51 


m 


61 


Resource-Priority 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 3) 





61a 


Retry-After 


[51 


m 


62 


Route 


[51 


m 


62a 


RSeq 


[51 


m 


63 


Security-Client 


[51 


n/a 


63a 


Security-Server 


[51 


n/a 


64 


Security-Verify 


[51 


n/a 


65 


Server 


[51 





65a 


Service-Route 


[51 


m on roaming ll-NNI, else n/a 


65b 


Session-ID 


[51 





66 


Session-Expires 


[51 


m 


66a 


SIP-ETag 


[51 


m in the case the PUBLISH request is supported, else n/a 
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Item 


Header field 


Ref. 


ll-NNI 


66b 


SIP-lf-Match 


[5] 


m in the case the PUBLISH request is supported, else n/a 


67 


Subject 


[5] 





67a 


Subscription-State 


[51 


m in the case the NOTIFY request is supported, else n/a 


68 


Supported 


[51 


m 


68a 


Target-Dialog 


[51 





69 


Timestamp 


[51 


m 


70 


To 


[51 


m 


71 


Trigger-Consent 


[51 


m 


71a 


Unsupported 


[51 


m 


72 


User-Agent 


[51 


m 


73 


User-to-User 


[51 





74 


Via 


[51 


m 


75 


Warning 


[51 





76 


www-Authenticate 


[51 


m on roaming ll-NNI, else n/a 



Table A.2: Key to notation codes for SIP header fields 



Notation 
code 


Meaning 


m 


The SIP header field is applicable at ll-NNI. 

Supporting a SIP header field at the ll-NNI means that this header field 
is passed through the IBCF. It does not imply that network elements 
inside the serving and served networks or user equipment connected 
to these networks shall support this header field, where 3GPP TS 
24.229 [51 is applied. If specified in 3GPP TS 24.229, the IBCF 
modifies the SIP header field. 





The applicability of SIP header field at ll-NNI depends on bilateral 
agreement between the operators. 


n/a 


It is impossible to use the SIP header field at the ll-NNI. This header 
field could be discarded by the IBCF. 
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